[00:09.080 --> 00:11.400]  Hey Bill, how do you pronounce your last name?
[00:12.980 --> 00:17.500]  You're not going to be able to say it, but it's Demir Kapo.
[00:18.420 --> 00:20.040]  Do you want me to try it?
[00:21.020 --> 00:25.880]  I mean, I don't care. I won't get offended if you don't say it.
[00:27.880 --> 00:29.940]  Looks like we are live.
[00:29.940 --> 00:32.180]  Yep, we seem to be live. Alright.
[00:33.220 --> 00:37.840]  Welcome everyone. I want to introduce Bill.
[00:37.840 --> 00:43.160]  Bill, I just tried to do your last name in my head, and I was not successful at it,
[00:43.160 --> 00:46.340]  so I'd like you to say it for everybody if you care to.
[00:47.120 --> 00:48.800]  Sure, it's Demir Kapo.
[00:48.800 --> 00:53.780]  Alright, thank you for that. Instead of me murdering that, I wanted you to try it.
[00:53.780 --> 00:59.520]  So, Bill did a talk on demystifying modern Windows rootkits.
[00:59.520 --> 01:02.880]  This is your opportunity to ask questions of Bill.
[01:02.880 --> 01:10.100]  So, there are a few questions already coming in through the TrackOne Live QA channel.
[01:10.100 --> 01:11.740]  Let's just go ahead and get started.
[01:12.760 --> 01:21.840]  Eragon asks, what are the easiest features to find that might reveal a modern rootkit via static analysis?
[01:23.260 --> 01:29.120]  I think a good place to start for static analysis is going to be the strings.
[01:29.120 --> 01:34.240]  Because if they leave any debug strings behind, or any unique strings for that specific binary,
[01:34.240 --> 01:37.760]  that's a good thing to maybe add to your signatures.
[01:37.760 --> 01:43.340]  But another opportunity is going to be the imports of the driver.
[01:43.340 --> 01:47.940]  For example, if a driver imports a bunch of undocumented functions,
[01:47.940 --> 01:50.420]  that's obviously going to be a little bit more suspicious,
[01:50.420 --> 01:56.300]  given that legitimate drivers tend to try to stick with what's documented and what's stable.
[01:56.300 --> 02:04.220]  So, if there's any functions that it imports that is not stable, or it's just not really known about,
[02:04.220 --> 02:06.020]  it's something to look at.
[02:06.180 --> 02:09.020]  So, anything undocumented that's getting pulled in,
[02:09.020 --> 02:14.220]  you're thinking that's going to be your opportunity for shenanigans on that side.
[02:17.060 --> 02:17.900]  Potential.
[02:18.600 --> 02:20.120]  What was that, Pasties?
[02:20.120 --> 02:22.540]  I was just going to say that. Potential shenanigans.
[02:22.540 --> 02:22.980]  Potential shenanigans.
[02:22.980 --> 02:23.980]  It could still be legitimate.
[02:23.980 --> 02:24.920]  Yeah, that's true.
[02:24.920 --> 02:29.860]  So, next question from RPTK2015.
[02:29.860 --> 02:34.020]  Did you actually find any P-key when searching in Greyhat?
[02:34.440 --> 02:38.980]  Mentioned in the context of using a legitimate key to sign your driver.
[02:39.600 --> 02:44.560]  Yes. So, I didn't, of course, crack any of them.
[02:44.560 --> 02:47.840]  But, I mean, some of them were pretty obviously related to code signing.
[02:47.840 --> 02:51.080]  For example, I remember one that had, like, code signing in its name.
[02:51.080 --> 02:55.600]  So, it was pretty clear that these were probably associated with code signing
[02:55.600 --> 03:01.320]  and that it's potentially, if you crack it, you could use it for kernel-mode code signing.
[03:01.320 --> 03:08.260]  It all depends on the type of certificate it is and, you know, what vendor it came from and stuff like that.
[03:08.260 --> 03:16.820]  But I have definitely, I can confirm that I've seen potentially viable private keys on Greyhat.
[03:17.340 --> 03:21.140]  Do you know if there are some keys that are, like, more trusted than others?
[03:21.140 --> 03:26.800]  Like, some that you can use to sign code but that aren't trusted for, like, kernel-level drivers or something like that?
[03:26.800 --> 03:32.600]  I assume, like, a Microsoft signing key is, like, gold, but...
[03:32.600 --> 03:38.260]  Yeah, yeah. So, usually how it works is that you have, like, these certificate companies
[03:38.260 --> 03:40.240]  that issue these code signing certificates.
[03:40.240 --> 03:44.260]  And they work with Microsoft to get what's called a cross-signing certificate.
[03:44.260 --> 03:50.200]  So, this means that Microsoft says, yes, you can use this vendor or this root authority
[03:50.200 --> 03:54.280]  can issue certificates for kernel-mode code signing, just to give you an example there.
[03:54.280 --> 03:57.740]  And so, what you can do there is you can...
[03:57.740 --> 04:03.360]  So, some vendors don't have a cross-signing cert and they probably will not work for kernel-mode code signing,
[04:03.360 --> 04:04.600]  while others do.
[04:05.100 --> 04:11.220]  And so, that's usually the different levels is whether or not the vendor has, you know,
[04:11.220 --> 04:15.340]  deals with Microsoft or has a cross-signing certificate from Microsoft.
[04:16.020 --> 04:21.000]  Where would I look up that information if I wanted to find out more of a specific cert?
[04:21.860 --> 04:27.020]  Yeah, so, I think Microsoft has, like, a list of cross-signing certificates on just their...
[04:28.360 --> 04:31.180]  on MSDN, Microsoft documentation.
[04:31.600 --> 04:37.540]  Yeah, I found a page here. It's, like, cross-certificates for kernel-mode code signing.
[04:38.340 --> 04:41.800]  Gotcha. Okay, so, a follow-up question on that one would be,
[04:41.800 --> 04:47.240]  what's a good place to find leaked certificates were I to decide I needed one?
[04:48.480 --> 04:53.920]  Yeah, so, one of the places I mentioned that it's a good place to start for looking for leaked certificates
[04:53.920 --> 04:58.460]  is going to be on the... so, cheating-related forums.
[04:58.460 --> 05:01.500]  There's quite a few available there that some of them have been out for years.
[05:01.620 --> 05:05.980]  And I still think that, so, you can use them because a lot of the...
[05:06.260 --> 05:10.780]  a lot of antivirus simply don't have detections in place for these leaked certificates,
[05:10.780 --> 05:12.880]  even ones that, again, have been out for years.
[05:12.960 --> 05:18.200]  So, if you're out looking for a leaked certificate, look at game-hacking forums,
[05:18.200 --> 05:22.220]  look, like, search for leaked certificates, and then the game-hacking forums' names,
[05:22.220 --> 05:26.060]  and I can guarantee you that you'll find some.
[05:26.060 --> 05:30.220]  That's an interesting crossover that totally makes a ton of sense, but I was...
[05:30.220 --> 05:33.580]  it's not something that would have come to mind if I was ever going to go look for that.
[05:35.380 --> 05:42.000]  Yeah, especially considering who's making these things and, you know, who builds a lot of the games out there.
[05:43.060 --> 05:44.900]  RPTK has another question there.
[05:44.900 --> 05:50.180]  Can you explain a little more about why would the kernel accept a driver signed by an expired certificate?
[05:50.920 --> 05:57.320]  Yes. So, when you see a... let's say you go into the digital signatures section of a driver,
[05:57.320 --> 06:01.140]  and you see a certificate there, and it says, this certificate has expired.
[06:01.140 --> 06:07.640]  Well, what you're seeing there when you go to the digital signatures section is the result of winVerifyTrust,
[06:07.640 --> 06:13.580]  which is a user-mode function, whereas the kernel-mode code-signing policy is completely different,
[06:13.580 --> 06:16.320]  because that's in the kernel.
[06:16.540 --> 06:21.380]  So what you see returned by the winVerifyTrust function will, generally speaking,
[06:21.380 --> 06:25.760]  not always be what the kernel-mode code-signing policy checks for.
[06:25.760 --> 06:30.640]  And what I mean by that is, if the winVerifyTrust returns, this is expired, or this is revoked.
[06:31.860 --> 06:38.060]  Some reasons that a kernel code... that you might be able to still load that driver is because,
[06:38.060 --> 06:41.440]  at the time of signing, it was still valid.
[06:41.720 --> 06:50.640]  So, even without a timestamp, the kernel just assumes that, since this was at some point signed by a valid certificate,
[06:50.640 --> 06:55.400]  even if the certificate expired, it still should be loaded.
[06:55.780 --> 06:57.500]  That seems like a problem.
[06:59.140 --> 07:00.180]  Yeah, it seems like an overstatement.
[07:00.180 --> 07:03.240]  Yeah, I think it's mostly going to be for compatibility reasons.
[07:03.260 --> 07:08.360]  That's what I'd, I guess, assume. But it's speculation, given that I don't work for Microsoft,
[07:08.360 --> 07:09.680]  so I don't know the reasoning behind it.
[07:09.680 --> 07:11.480]  I'm sure there's a whole lot of history there.
[07:11.980 --> 07:14.480]  So we have another question.
[07:15.620 --> 07:22.660]  Trinsky is asking if you have any interest in creating a roadmap of resources, courses, or tutorials on your blog,
[07:22.780 --> 07:26.480]  a person can get to your level of reverse engineering competency.
[07:27.360 --> 07:34.800]  Yeah, so, for that question, it's mostly, you know, most of my, I guess, knowledge comes from just experience.
[07:34.800 --> 07:40.940]  And the best recommendation I can really give is to just try things out, you know, do CTFs.
[07:40.940 --> 07:43.860]  If you want to learn reverse engineering, you know, do the CTS.
[07:44.140 --> 07:50.080]  And really, you know, one of the ways that I go about, you know, looking for even projects or stuff to do,
[07:50.080 --> 07:53.560]  is I always stay curious. And what I mean by that is,
[07:53.560 --> 07:59.340]  if I see some weird functionality by a program I'm using, like in real life, on my machine,
[07:59.340 --> 08:03.860]  I will probably quickly try to check underneath of what's happening here.
[08:03.860 --> 08:06.040]  You know, why is it doing this one weird thing?
[08:06.040 --> 08:10.980]  And oftentimes, I've found that that can actually lead to other issues, like actual security issues.
[08:10.980 --> 08:15.260]  So if you're looking for what, you know, what projects to do or what to reverse,
[08:15.260 --> 08:18.660]  it's really just going to be the software you use in your everyday life.
[08:18.660 --> 08:27.220]  And I don't have any plans to do like a course or something on just, you know, tutorials on how to reverse engineer, for example.
[08:27.220 --> 08:35.600]  But it's going to be really going out and finding your own projects that you find interesting,
[08:35.600 --> 08:40.360]  so that you'll continue pursuing it. That's, I guess, the trick I did.
[08:40.360 --> 08:45.440]  The reason that I was able to learn so fast was because I always did stuff I was always interested in.
[08:45.440 --> 08:48.280]  And that was, you know, in specifically game hacking.
[08:48.280 --> 08:51.360]  I love games, and I'm bad at games.
[08:51.360 --> 08:56.180]  So I had a, you know, self-interest to continue reverse engineering these games,
[08:56.180 --> 09:00.120]  and figuring out how they work, and maybe how the anti-cheat works.
[09:00.120 --> 09:04.700]  And then you'll end up learning a lot from just, you know, trying out things,
[09:04.700 --> 09:09.980]  trying to reverse new programs you might have not had looked at before, stuff like that.
[09:09.980 --> 09:15.420]  Well, a quick step back then. So you said you watch as a program does something unusual.
[09:15.420 --> 09:20.800]  It's not exactly the words you used, but what types of unusual things are you expecting?
[09:20.800 --> 09:24.540]  What types of things would make the radar go off?
[09:24.980 --> 09:28.880]  So just to give you an example of like a vulnerability I found a few years ago,
[09:28.880 --> 09:32.320]  was in the software called Dell Support Assist.
[09:32.320 --> 09:38.280]  And how that worked was when I went to update my drivers, because I installed a new SSD,
[09:38.280 --> 09:40.400]  I needed drivers for that one machine.
[09:40.400 --> 09:45.640]  The website claimed to be able to update my drivers, but from the website itself.
[09:45.660 --> 09:48.500]  And I was like, how does a website update my drivers?
[09:48.500 --> 09:54.320]  Well, it turns out that Dell pre-installs this software that basically allows its own website
[09:54.320 --> 09:58.120]  to communicate with it and install stuff like updates.
[09:58.120 --> 10:02.000]  Well, that's kind of weird, you know, because you're allowing a website to have that sort of access.
[10:02.000 --> 10:07.680]  And then I reverse engineered it further, and I found that the restrictions there weren't quite as strong.
[10:07.680 --> 10:12.360]  And I found a way to bypass the restrictions the application had.
[10:12.680 --> 10:17.660]  But so the weird part there was, well, it's a website claiming to, you know, update my drivers.
[10:17.660 --> 10:24.080]  That's not normal. Websites, it normally can't just do it automatically update my drivers itself.
[10:24.180 --> 10:26.560]  You know, it might be something I have to install and do it myself.
[10:26.560 --> 10:28.440]  But so in that case, that was something weird.
[10:28.440 --> 10:32.400]  It's just basically finding these, you know, why does this thing happen?
[10:32.400 --> 10:34.200]  Why did they design it this way?
[10:34.200 --> 10:40.760]  And it's looking for those logical flaws in their, like, design or just their code itself.
[10:40.900 --> 10:44.660]  Yeah. So this is one that I've actually hit myself.
[10:45.980 --> 10:50.080]  RPTK2015 asking another question, like, keep them coming.
[10:50.080 --> 10:53.720]  This dude's pretty orchic. I don't know.
[10:54.000 --> 10:57.940]  Could you explain on how secure boot blocks some of the driver signing methods?
[10:57.940 --> 11:01.160]  I've definitely noticed that some drivers work with UEFI and some don't.
[11:01.160 --> 11:03.260]  And it's usually a driver signature problem.
[11:03.260 --> 11:14.200]  Yeah. So the main issue you're going to have with secure boot is if you're, like, going after using a leaked certificate or if you're buying your own certificate,
[11:14.200 --> 11:20.980]  the thing to consider is if the certificate was issued after July 29th, 2015, that's the cutoff date.
[11:20.980 --> 11:27.400]  Then you're going to need a EV certificate, so extended validation certificate on newer versions of Windows 10.
[11:27.400 --> 11:36.640]  So what that means is you're going to have to, basically, the certificate vendors that give you these code signing certificates have to, you know, do extra validation.
[11:36.640 --> 11:42.520]  And typically the certificate is given to you on, like, a USB drive instead of just sending you the private key file.
[11:42.800 --> 11:48.600]  So that, you know, for versions of Windows 10 that have secure boot enabled,
[11:48.600 --> 11:56.140]  you're basically preventing drivers that aren't signed with an EV certificate to be loaded just because that's the policy that follows.
[11:56.140 --> 12:04.320]  And in those newer versions. And so, but if your leaked certificate was released before, issued before July 29th, 2015,
[12:04.320 --> 12:11.540]  then it will still work on these newer builds with this secure boot protection, I guess you call it.
[12:11.820 --> 12:22.080]  There is sort of an extension of that. When I encountered this issue, there was a registry flag that you could set that was sort of bypassed it.
[12:22.080 --> 12:25.760]  It was unattended upgrade. It was from Windows 7 to Windows 10 upgrade.
[12:25.760 --> 12:28.900]  Did you try playing around with that to see if we might?
[12:29.500 --> 12:36.560]  I know, mostly because the leaked certificates, like you can just, the ones publicly available are issued before that cutoff date.
[12:36.700 --> 12:40.300]  So, I mean, it's like, there's like, almost all of them are issued.
[12:40.300 --> 12:46.320]  I mean, at least right now, you know, the leaked certificates I used was when I found it was issued before that date.
[12:46.320 --> 12:50.400]  So I haven't actually found the leaked certificate that was issued after it yet.
[12:50.400 --> 12:55.740]  So it's easy enough to find it that you haven't had to hunt down that possible other way to get it done.
[12:57.080 --> 13:03.360]  Right, right, right. And so there's quite a number of ways you can approach the problem of, you know, getting your driver loaded.
[13:03.420 --> 13:12.040]  And at that point, well, if you don't even need to look into, you know, other ways there, it's a non-issue, I guess you call it.
[13:12.040 --> 13:20.740]  But it's something to keep in mind, you know, going forward, once those leaked certificates start to run out, you're probably going to run into that issue of that date restriction.
[13:20.740 --> 13:32.080]  And at that point, I'd probably recommend the second method of loading a driver and abusing another legitimate driver that has been signed with like an EV certificate.
[13:32.280 --> 13:40.040]  But again, the problem with that, in my talk, I mentioned it is that you can run into a lot of stability issues when abusing another driver and trying to load your own.
[13:40.040 --> 13:45.120]  Just because there's oftentimes going to be stability concerns like race conditions.
[13:45.840 --> 13:47.200]  That makes sense.
[13:49.980 --> 13:55.340]  So Trunsky is asking, did you test your rootkit against any of the top EDRs?
[13:55.840 --> 14:01.720]  No, I didn't. But I took EDRs into consideration when designing the application.
[14:01.720 --> 14:07.620]  And for example, how I hook communication between the AFT driver and user mode applications.
[14:07.620 --> 14:13.880]  I always went for methods that would try to make it as expensive as possible to detect.
[14:13.880 --> 14:18.600]  Because I feel like that's the best approach is not security through obscurity.
[14:18.600 --> 14:27.620]  It's going to be, how can I make the antivirus have to go through a very expensive and time-consuming process to detect me?
[14:27.620 --> 14:30.600]  Because oftentimes they'll reconsider for those reasons.
[14:30.600 --> 14:35.680]  Or another perspective might be, how can I cause compatibility issues?
[14:35.680 --> 14:43.120]  If there's an application that already does these suspicious operations, maybe I can impersonate that application.
[14:43.120 --> 14:48.260]  And the antivirus would have to accept it because the legitimate application also does suspicious operations.
[14:48.260 --> 14:52.120]  Trigger bad false positives that they can't work around themselves.
[14:52.440 --> 14:55.720]  Right, right, right. Or it's very difficult to detect around that.
[14:56.700 --> 14:58.600]  Yeah, makes sense.
[14:58.600 --> 15:04.440]  Yeah, I feel like a lot of security is just making the other side do more work to get to the same goal.
[15:06.980 --> 15:10.180]  So RPTK asks another question here.
[15:10.560 --> 15:17.260]  There were some methods you were able to see that were not HVCI compatible.
[15:17.260 --> 15:21.000]  Can you please explain a little bit about HVCI mitigations?
[15:22.280 --> 15:26.960]  Yeah, so the HVCI, let me look what it stands for.
[15:26.960 --> 15:30.620]  It's like, yeah, virtualization-based protection of code integrity.
[15:30.620 --> 15:33.500]  So essentially what it does is it's a mitigation.
[15:33.500 --> 15:36.720]  If you have virtualization enabled, you should be able to enable it.
[15:36.720 --> 15:43.960]  That basically makes it so once the driver is loaded into memory, especially its executable sections,
[15:43.960 --> 15:48.240]  it can never again have those executable sections set to writable.
[15:48.720 --> 15:58.420]  The memory protections will never be able to be writable for that memory page because it's an executable section.
[15:58.420 --> 16:06.920]  So essentially it prevents code hooking, for example, or basically modifying the actual bytes of the driver's executable code.
[16:07.780 --> 16:09.580]  That makes sense.
[16:12.260 --> 16:19.420]  So I apparently missed this. Can you talk a little bit about your Peacemaker project and how it compares to Spectre?
[16:20.680 --> 16:31.840]  Sure. So Peacemaker was a proof-of-concept EDR that I wrote a few months ago, which was basically the opposite of what I'm doing now.
[16:31.840 --> 16:35.960]  Instead of writing a rootkit, I wrote a driver to detect malware.
[16:36.240 --> 16:44.940]  And the biggest difference between the two is the fact that one of them is a blue-teaming defense application while the other one is a rootkit.
[16:45.260 --> 16:48.020]  But how does it compare?
[16:48.020 --> 16:54.020]  Well, Peacemaker is going to be... I believe it's a little bit less efficient in general.
[16:54.020 --> 17:01.400]  And I followed a stricter code design policy for myself in this latest one.
[17:01.400 --> 17:08.300]  So, I mean, those are, I guess, how it compares. But they're two different projects for two different reasons.
[17:10.100 --> 17:17.200]  That's fair. So speaking about other projects and other places you might want to push this research...
[17:17.800 --> 17:30.920]  You already mentioned a little bit about a gap of the upgrade process for if you end up running out of certificates that were signed before the cutoff date.
[17:30.920 --> 17:37.920]  What other interesting things are out there for somebody who wants to do research in the same field that you're in?
[17:37.920 --> 17:44.300]  What would you recommend for somebody who is looking for a neat project to jump in and start working?
[17:45.900 --> 17:52.440]  So for, I guess, neat projects of where to start, it would first of all be...
[17:52.440 --> 17:58.100]  If you're interested in learning more about the Windows kernel or the internals of the Windows operating system,
[17:58.100 --> 18:02.960]  the best recommendation I have, besides experience, is going to be...
[18:02.960 --> 18:08.080]  Some of the books out there include the Windows internals, 7th edition is the latest one,
[18:08.080 --> 18:12.580]  that really goes into depth about the internals of the Windows operating system.
[18:12.580 --> 18:21.200]  But it's really going to be finding a way to make security interesting for you or make learning interesting to you.
[18:21.200 --> 18:25.080]  And that's the best way I can recommend, I guess, of how to...
[18:25.080 --> 18:34.660]  What's the best way to go about learning these difficult topics is to gamify it and is to incentivize the research itself.
[18:35.920 --> 18:39.660]  But yeah, in general, it's going to be...
[18:39.660 --> 18:46.060]  Most of your experience and knowledge is going to come from experience and just playing with things, trying new things.
[18:46.060 --> 18:49.920]  And for projects you could do, it varies.
[18:49.920 --> 18:55.820]  You can try looking at reversing drivers for vulnerabilities in their IOCTL interface.
[18:55.820 --> 18:58.760]  That's what I started with, at least.
[18:59.020 --> 19:03.640]  And you can try to find a way to abuse those drivers.
[19:03.640 --> 19:06.260]  Like the abuse legitimate drivers portion.
[19:06.260 --> 19:13.760]  If you're looking for some drivers to, I guess, that might be vulnerable, a lot of OEM drivers have security issues in them.
[19:14.200 --> 19:15.820]  I'm always shocked.
[19:16.680 --> 19:18.980]  I've become desensitized to it.
[19:18.980 --> 19:24.100]  Almost every OEM driver has something questionable in it.
[19:24.380 --> 19:29.280]  And I guess that's the place to start if you're looking for vulnerable drivers.
[19:29.280 --> 19:36.720]  It almost sounds like as you're approaching these projects, the new thing pops out at you.
[19:36.720 --> 19:43.000]  Maybe not from getting a depth into, hey, I'm going to find all of the drivers out there.
[19:43.000 --> 19:47.040]  But you're looking for other things, you're learning everything you can.
[19:47.040 --> 19:51.820]  And then the context for your next project kind of filters out from that.
[19:51.820 --> 19:56.520]  Or do you find that you have to go searching for what you're going to attack next?
[19:57.640 --> 20:00.900]  In general, not even just Windows Kernel stuff.
[20:01.040 --> 20:04.720]  I generally don't search for projects to do.
[20:04.720 --> 20:07.520]  Again, it's just finding stuff that might be interesting.
[20:07.920 --> 20:12.940]  If a program is doing something suspicious, there you go, that's a project right there.
[20:12.940 --> 20:14.780]  Find out why it's doing that thing.
[20:14.780 --> 20:18.720]  Or anything similar it's doing that could be called into question.
[20:18.720 --> 20:28.380]  But for Windows Kernel, one thing I do is I try to get part of the virus scanning platforms out there.
[20:28.380 --> 20:30.560]  One I am part of is hybrid analysis.
[20:30.560 --> 20:33.940]  And what I'll do is I'll occasionally search for drivers on there and download them.
[20:33.940 --> 20:37.880]  And just take a quick peek under the hood and you can see what's going on there.
[20:38.280 --> 20:42.780]  And so that's a good place to find these driver files if you're trying to search for them.
[20:43.840 --> 20:45.080]  Sorry, go ahead.
[20:45.080 --> 20:47.800]  I was going to say, are those already infected drivers?
[20:47.800 --> 20:53.120]  Or are these just tons of driver repository kind of thing?
[20:53.280 --> 20:57.520]  It's just a repository. These aren't necessarily bad drivers or vulnerable drivers.
[20:57.520 --> 21:01.520]  These are just potent, might be legitimate drivers as well.
[21:01.520 --> 21:03.300]  So it's just a driver repository.
[21:04.760 --> 21:09.880]  Have you looked at any other driver infections just to see how they are doing those hooks?
[21:09.880 --> 21:15.700]  Get basically similar ideas and work back from the attack side rather than being like, oh, this is weird.
[21:15.800 --> 21:18.780]  Instead of like, oh, this is an active attack, how are they doing this?
[21:18.780 --> 21:21.020]  Could this apply to other situations?
[21:21.520 --> 21:26.120]  So basically, do you look at malware or do you just look for new things in weird drivers?
[21:26.700 --> 21:29.400]  I look for new things in weird drivers.
[21:29.500 --> 21:33.300]  I don't specifically just look at drivers I know that are malicious.
[21:34.460 --> 21:38.160]  What I do is I'll reverse engineer, like I said, OEM drivers.
[21:38.160 --> 21:40.940]  And that's a starting point. Those are legitimate.
[21:40.940 --> 21:44.660]  And I'll just look into what I can find.
[21:45.080 --> 21:49.440]  First of all, it's like auditing attack surfaces, finding out what can you actually talk to.
[21:49.540 --> 21:52.960]  And then it's finding out now you know what you can talk to.
[21:52.960 --> 21:58.120]  What are the access controls in place that limit how much you can talk to the application?
[21:58.200 --> 22:04.420]  And it's going from there. It's that type of investigation of what can you access and how can you manipulate what you can access.
[22:05.820 --> 22:06.820]  Cool.
[22:07.120 --> 22:11.560]  So Truinsky asked a question that fits into kind of the direction I was pointing there.
[22:11.560 --> 22:14.700]  How do you balance your personal life and doing research?
[22:14.700 --> 22:18.580]  So you're clearly deeply involved in this.
[22:18.580 --> 22:26.600]  At what point is this all you do and how do you fit in the rest of the stuff you want to do with your life?
[22:27.660 --> 22:31.420]  Yes. So, well, specifically how I manage my time is going to...
[22:31.940 --> 22:38.000]  The big thing is, you know, over the summer I didn't do most of my most of my research was before I was in school.
[22:38.040 --> 22:41.080]  So before, you know, any internship or summer work.
[22:41.200 --> 22:46.040]  So it's going to be in school. I've just I've got too much free time.
[22:46.960 --> 22:53.580]  And so I just spend that time researching or, you know, I spend some of that time trying to research things.
[22:53.580 --> 22:57.600]  And it's different. You know, if you have a full time job, I don't know if I have a recommendation for you.
[22:57.600 --> 23:01.960]  Because a fact is, I know how like 40 hours a week is rough.
[23:02.820 --> 23:06.260]  You know, you'll probably be tired when you get home.
[23:06.260 --> 23:09.660]  So, you know, doing research then it can be difficult sometimes.
[23:09.660 --> 23:12.340]  And so I don't know if I have any recommendations specific to that.
[23:12.340 --> 23:18.820]  But in general, I try to use this free time I have as much as possible, like valuably, I guess.
[23:19.100 --> 23:26.240]  And since I have so much free time in school, you know, I dedicate a portion of that to doing my own research.
[23:27.620 --> 23:28.860]  That's awesome.
[23:29.400 --> 23:38.480]  So not that we want to point towards anything specific, but you did mention that there were some CTFs out there that are good training resources.
[23:38.620 --> 23:44.860]  Maybe this is a good time for you to say, do you have a favorite CTF for teaching this type of material?
[23:44.860 --> 23:51.960]  Other than, you know, you were talking about the Windows, Windows internal stuff that you can read the 30 pound book.
[23:52.540 --> 23:58.540]  So it's actually unfortunate. I find that a lot of CTFs don't really focus on Windows related challenges.
[23:58.540 --> 24:04.000]  It's really rare you'll see like an actual challenge that's dedicated about Windows internals.
[24:04.000 --> 24:11.000]  It's usually, you know, like if it's like a binary exploitation thing, generally speaking, I see it being like Linux application, right?
[24:11.120 --> 24:13.800]  Maybe running even on the ARM architecture.
[24:13.880 --> 24:18.640]  But I just rarely see I don't have any good CTFs to recommend for Windows related stuff.
[24:18.640 --> 24:24.060]  Just because oftentimes you probably won't see Windows related stuff.
[24:24.280 --> 24:28.240]  One of them I can I know I can mention that it's pretty good.
[24:28.240 --> 24:33.680]  It's I guess you call my favorite CTF overall is the Flareon reversing CTF.
[24:33.700 --> 24:35.740]  They have some really interesting challenges there.
[24:35.740 --> 24:37.520]  You know, it's not just going to be Windows stuff.
[24:37.520 --> 24:43.760]  It's going to be, you know, reversing a bunch of different architectures and applications, figuring out what they do.
[24:44.280 --> 24:47.460]  It's one of the favorite ones I participate in.
[24:49.100 --> 24:53.980]  Also, I mean, I guess that also kind of exposes like that CTF sounds awesome.
[24:53.980 --> 24:57.900]  It seems like any for anyone that's watching that there's a gap in the community.
[24:58.080 --> 25:01.380]  Windows CTFs. There you go.
[25:03.100 --> 25:04.800]  Next DEF CON talk.
[25:06.720 --> 25:08.540]  Well, so what's next for you?
[25:08.540 --> 25:13.100]  If you could pick which direction you would point for your for your next research topic?
[25:15.260 --> 25:18.120]  That's simple to say, I honestly don't have a next direction.
[25:18.160 --> 25:19.920]  I don't have the next project.
[25:19.920 --> 25:22.520]  I'm again, I kind of just go with the flow.
[25:22.620 --> 25:29.300]  I see it really is literally just looking at the everyday software I use.
[25:29.300 --> 25:33.660]  And then if I know that I just tend to notice stuff like this is weird.
[25:33.660 --> 25:37.960]  And that's how I how I go about doing it for this specific for my talk.
[25:37.960 --> 25:44.160]  I came up with it, I guess you could say is is our schools or our schools security club.
[25:44.200 --> 25:50.960]  A red team needed a new we wanted new malware to use against our best blue team competitors.
[25:50.960 --> 25:55.360]  So we run competitions where we do like we simulate a corporate environment.
[25:55.360 --> 26:00.460]  And you have a red team that tries to maintain persistence and a blue team that tries to kick you out.
[26:00.460 --> 26:07.140]  Blue teams also have like uptime and these challenges that they have to keep services up while the red team tries to mess with them.
[26:07.140 --> 26:13.520]  And so there was just a need there for me to develop some tooling against our top blue teamers.
[26:13.820 --> 26:18.560]  And so that's why I decided to look into this, you know, maybe like two birds with one stone type thing.
[26:18.560 --> 26:20.100]  You know, I thought it'd be interesting.
[26:20.820 --> 26:25.600]  So there's educational resources about rootkits out there like books, I know for sure.
[26:25.720 --> 26:32.680]  But I haven't really seen open source tooling around, you know, kernel level Windows rootkits out there.
[26:32.680 --> 26:34.100]  It's rare to see it.
[26:34.100 --> 26:36.920]  So I thought it would actually be a pretty interesting project.
[26:38.920 --> 26:40.580]  Looks like it turned out that way.
[26:41.720 --> 26:44.380]  Did you end up crushing the blue team with this?
[26:45.740 --> 26:47.320]  Yes, yes, definitely.
[26:47.420 --> 26:55.780]  I remember having conversations about, you know, like, when I suggested that I was abusing legitimate communication,
[26:55.780 --> 26:58.140]  explaining to these blue teamers how I was doing things.
[26:58.200 --> 27:03.200]  They were really confused about, you know, like, how would you abuse a legitimate port on my machine?
[27:03.200 --> 27:06.900]  Because they were looking for malware and I was using...
[27:06.900 --> 27:09.760]  So they have to have certain services uptime, right?
[27:09.760 --> 27:12.380]  So they have to have these services always up.
[27:12.480 --> 27:16.320]  So I was just using that fact to get into their machine.
[27:16.320 --> 27:18.700]  Because they could, like, take down that service.
[27:18.700 --> 27:24.220]  So even if they knew, and they didn't, that I was abusing these legitimate services for communication,
[27:24.220 --> 27:27.780]  you know, they would firewall everything except for those services.
[27:27.780 --> 27:32.480]  And I'd still be able to get access because, you know, communicating through their services.
[27:32.480 --> 27:35.720]  Yeah, it was a really fun time.
[27:37.740 --> 27:43.320]  One person is asking for a clarification on the CTF, like, where they can find it, the Flareon.
[27:43.320 --> 27:47.500]  They found flare-on.com.
[27:47.720 --> 27:50.480]  Yeah, it is the Flareon.
[27:50.480 --> 27:53.700]  Flare-on.com is the one I mentioned.
[27:53.820 --> 27:57.340]  And another question from RPTK2015.
[27:57.340 --> 28:02.340]  In the resources you proposed, ReactOS, could you explain a little bit about that?
[28:02.980 --> 28:09.940]  Yeah, sure. So ReactOS is essentially a bunch of engineers, reverse-engineered Windows kernel,
[28:09.940 --> 28:12.440]  and wrote it one-to-one.
[28:12.440 --> 28:15.280]  I wouldn't say, obviously, it's not one-to-one 100%,
[28:15.280 --> 28:19.800]  but it's actually, like, insanely accurate of the actual Windows kernel.
[28:19.800 --> 28:22.760]  So it's kind of like an open-source Windows kernel.
[28:22.760 --> 28:27.740]  You'll find that a lot of the functions in the actual kernel has been re-implemented in there.
[28:27.740 --> 28:33.540]  It follows the same structure. It's just quite literally an open-source clone of Windows.
[28:34.000 --> 28:39.180]  And it's an amazing resource because sometimes you'll find undocumented functions.
[28:39.180 --> 28:40.420]  You don't know what it does.
[28:40.420 --> 28:45.640]  And luckily, you can go to the ReactOS project and just take a look at the source of that
[28:45.640 --> 28:49.560]  because people have spent hours reversing that one function for you.
[28:49.560 --> 28:54.780]  Now, some of this is going to be outdated because the ReactOS kernel replicates the XP kernel.
[28:54.900 --> 28:58.810]  But still, the core functionality is going to be pretty similar.
[29:00.500 --> 29:03.980]  Excellent. So we are right at the end of our scheduled time.
[29:03.980 --> 29:10.300]  Is there anything else you'd like to impart upon us before we call it for the day?
[29:11.320 --> 29:15.760]  Yeah, I mean, not really. I appreciate everyone for coming out to my talk.
[29:15.760 --> 29:24.760]  Keep in mind that I'd like more red teamers to start using Windows kernel-level rootkits
[29:24.760 --> 29:28.760]  and going that route because I think there's some interesting...
[29:29.320 --> 29:31.040]  more advanced actors use it.
[29:31.040 --> 29:36.580]  And I feel like more red teamers need to start simulating those advanced actors
[29:36.580 --> 29:39.820]  that have been using these rootkit techniques for years.
[29:39.820 --> 29:43.840]  I just feel like we have such a good community for user-mode malware.
[29:43.840 --> 29:49.040]  But we rarely see much for kernel-mode, if that makes sense.
[29:49.040 --> 29:53.000]  So I guess that's the parting message is please start looking into it
[29:53.000 --> 29:58.140]  because the real adversaries out there already have this ready to go.
[29:58.280 --> 30:03.900]  That makes sense. Well, we'll get you to post all of your contact information into track one
[30:03.900 --> 30:09.440]  and let people find you wherever you tell them that they can find you.
[30:09.440 --> 30:15.160]  And I really appreciate that you gave us some time today to both give that presentation
[30:15.160 --> 30:17.440]  and then spend this time in the Q&A.
[30:17.660 --> 30:22.700]  So thank you very much and hopefully we'll see more from you soon.
[30:23.240 --> 30:25.360]  Yep. Have a good one.
[30:25.360 --> 30:26.340]  Thank you, Bill.
[30:26.340 --> 30:26.980]  Thanks, guys.
